home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxx / rfc878 < prev    next >
Text File  |  1995-07-25  |  75KB  |  3,011 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.      Request for Comments: 878
  7.      Obsoletes RFCs: 851, 802
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.                   The ARPANET 1822L Host Access Protocol
  17.  
  18.  
  19.  
  20.                                   RFC 878
  21.  
  22.  
  23.  
  24.  
  25.  
  26.                               Andrew G. Malis
  27.                        ARPANET Mail: malis@bbn-unix
  28.  
  29.  
  30.  
  31.  
  32.  
  33.                          BBN Communications Corp.
  34.                               50 Moulton St.
  35.                            Cambridge, MA  02238
  36.  
  37.  
  38.  
  39.  
  40.  
  41.                                December 1983
  42.  
  43.  
  44.  
  45.  
  46.  
  47.      This RFC specifies the ARPANET 1822L Host Access Protocol,  which
  48.      is  a successor to the existing 1822 Host Access Protocol.  1822L
  49.      allows ARPANET hosts to use  logical  names  as  well  as  1822's
  50.      physical port locations to address each other.
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.      1822L Host Access Protocol                          December 1983
  64.      RFC 878
  65.  
  66.  
  67.  
  68.                              Table of Contents
  69.  
  70.  
  71.  
  72.  
  73.  
  74.      1   INTRODUCTION.......................................... 1
  75.  
  76.      2   THE ARPANET 1822L HOST ACCESS PROTOCOL................ 3
  77.      2.1   Addresses and Names................................. 5
  78.      2.2   Name Translations................................... 7
  79.      2.2.1   Authorization and Effectiveness................... 7
  80.      2.2.2   Translation Policies............................. 11
  81.      2.2.3   Reporting Destination Host Downs................. 13
  82.      2.2.4   1822L and 1822 Interoperability.................. 15
  83.      2.3   Uncontrolled Packets............................... 16
  84.      2.4   Establishing Host-IMP Communications............... 19
  85.      2.5   Counting RFNMs When Using 1822L.................... 20
  86.      2.6   1822L Name Server.................................. 23
  87.  
  88.      3   1822L LEADER FORMATS................................. 25
  89.      3.1   Host-to-IMP 1822L Leader Format.................... 26
  90.      3.2   IMP-to-Host 1822L Leader Format.................... 34
  91.  
  92.      4   REFERENCES........................................... 42
  93.  
  94.      A   1822L-IP ADDRESS MAPPINGS............................ 43
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.                                    - i -
  119.  
  120.  
  121.  
  122.      1822L Host Access Protocol                          December 1983
  123.      RFC 878
  124.  
  125.  
  126.  
  127.                                   FIGURES
  128.  
  129.  
  130.  
  131.  
  132.      2.1  1822 Address Format.................................. 5
  133.      2.2  1822L Name Format.................................... 6
  134.      2.3  1822L Address Format................................. 6
  135.      3.1  Host-to-IMP 1822L Leader Format..................... 27
  136.      3.2  NDM Message Format.................................. 30
  137.      3.3  IMP-to-Host 1822L Leader Format..................... 35
  138.      3.4  Name Server Reply Format............................ 38
  139.      A.1  1822 Class A Mapping................................ 44
  140.      A.2  1822L Class A Mapping............................... 44
  141.      A.3  1822L Class B Mapping............................... 45
  142.      A.4  1822L Class C Mapping............................... 46
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.                                   - ii -
  178.  
  179.  
  180.  
  181.      1822L Host Access Protocol                          December 1983
  182.      RFC 878
  183.  
  184.  
  185.  
  186.      1  INTRODUCTION
  187.  
  188.  
  189.      This RFC specifies the ARPANET 1822L Host Access Protocol,  which
  190.  
  191.      will allow hosts to use logical addressing (i.e., host names that
  192.  
  193.      are independent of their physical location  on  the  ARPANET)  to
  194.  
  195.      communicate  with  each  other.  This new host access protocol is
  196.  
  197.      known as the ARPANET 1822L (for Logical)  Host  Access  Protocol,
  198.  
  199.      and  is  a  successor  to  the  current  ARPANET 1822 Host Access
  200.  
  201.      Protocol, which is described in  sections  3.3  and  3.4  of  BBN
  202.  
  203.      Report  1822  [1].   Although  the  1822L protocol uses different
  204.  
  205.      Host-IMP leaders than the 1822 protocol, the IMPs  will  continue
  206.  
  207.      to support the 1822 protocol, and hosts using either protocol can
  208.  
  209.      readily communicate with each other (the  IMPs  will  handle  the
  210.  
  211.      translation automatically).
  212.  
  213.  
  214.      The RFC's terminology is consistent  with  that  used  in  Report
  215.  
  216.      1822, and any new terms will be defined when they are first used.
  217.  
  218.      Familiarity  with  Report  1822  (section  3  in  particular)  is
  219.  
  220.      assumed.   As could be expected, the RFC makes many references to
  221.  
  222.      Report 1822.  As a result, it uses, as a convenient abbreviation,
  223.  
  224.      "see 1822(x)" instead of "please refer to Report 1822, section x,
  225.  
  226.      for further details".
  227.  
  228.  
  229.      This RFC updates, and obsoletes, RFC 851.  The changes from  that
  230.  
  231.      RFC are:
  232.  
  233.  
  234.  
  235.  
  236.                                    - 1 -
  237.  
  238.  
  239.  
  240.      1822L Host Access Protocol                          December 1983
  241.      RFC 878
  242.  
  243.  
  244.  
  245.      o Section 2.2.4 was rewritten for clarity.
  246.  
  247.  
  248.      o Section 2.5 was expanded to  further  discuss  the  effects  of
  249.  
  250.        using 1822L names on host-to-host virtual circuits.
  251.  
  252.  
  253.      o In section 3.2, the type 1  IMP-to-host  message  has  two  new
  254.  
  255.        subtypes,  the type 9 message has one new subtype, and the type
  256.  
  257.        15, subtype 4 message is no longer defined.
  258.  
  259.  
  260.      o An appendix describing the  mapping  between  1822L  names  and
  261.  
  262.        internet (IP) addresses has been added.
  263.  
  264.  
  265.      All of these changes to RFC 851 are marked by revision  bars  (as  |
  266.  
  267.      shown here) in the right margin.                                   |
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.                                    - 2 -
  296.  
  297.  
  298.  
  299.      1822L Host Access Protocol                          December 1983
  300.      RFC 878
  301.  
  302.  
  303.  
  304.      2  THE ARPANET 1822L HOST ACCESS PROTOCOL
  305.  
  306.  
  307.      The ARPANET 1822L Host Access  Protocol  allows  a  host  to  use
  308.  
  309.      logical  addressing  to  communicate  with  other  hosts  on  the
  310.  
  311.      ARPANET.  Basically, logical addressing allows hosts to refer  to
  312.  
  313.      each  other  using  an  1822L  name  (see  section  2.1) which is
  314.  
  315.      independent of a host's physical location in  the  network.   IEN
  316.  
  317.      183  (also  published  as  BBN  Report 4473) [2] gives the use of
  318.  
  319.      logical  addressing  considerable   justification.    Among   the
  320.  
  321.      advantages it cites are:
  322.  
  323.  
  324.      o The ability to refer to each host on  the  network  by  a  name
  325.  
  326.        independent of its location on the network.
  327.  
  328.  
  329.      o Allowing different hosts to share  the  same  host  port  on  a
  330.  
  331.        time-division basis.
  332.  
  333.  
  334.      o Allowing a host to use multi-homing (where a single  host  uses
  335.  
  336.        more than one port to communicate with the network).
  337.  
  338.  
  339.      o Allowing several hosts that provide the same service  to  share
  340.  
  341.        the same name.
  342.  
  343.  
  344.      The main differences between the 1822 and 1822L protocols are the
  345.  
  346.      format of the leaders that are used to introduce messages between
  347.  
  348.      a host and an IMP, and the specification in those leaders of  the
  349.  
  350.      source  and/or  destination  host(s).   Hosts  have the choice of
  351.  
  352.  
  353.  
  354.                                    - 3 -
  355.  
  356.  
  357.  
  358.      1822L Host Access Protocol                          December 1983
  359.      RFC 878
  360.  
  361.  
  362.  
  363.      using the 1822 or the 1822L protocol.  When a host comes up on an
  364.  
  365.      IMP,  it  declares  itself to be an 1822 host or an 1822L host by
  366.  
  367.      the type of NOP message (see section  3.1)  it  uses.   Once  up,
  368.  
  369.      hosts  can  switch  from  one protocol to the other by issuing an
  370.  
  371.      appropriate NOP.  Hosts that do not use the 1822L  protocol  will
  372.  
  373.      still  be  addressable by and can communicate with hosts that do,
  374.  
  375.      and vice-versa.
  376.  
  377.  
  378.      Another difference between the two protocols  is  that  the  1822
  379.  
  380.      leaders are symmetric, while the 1822L leaders are not.  The term
  381.  
  382.      symmetric means that in the 1822 protocol, the exact same  leader
  383.  
  384.      format  is used for messages in both directions between the hosts
  385.  
  386.      and IMPs.  For example, a leader sent from a host  over  a  cable
  387.  
  388.      that  was  looped  back onto itself (via a looping plug or faulty
  389.  
  390.      hardware) would arrive back at the host and appear to be a  legal
  391.  
  392.      message  from  a  real host (the destination host of the original
  393.  
  394.      message).  In contrast, the 1822L headers are not symmetric,  and
  395.  
  396.      a  host  can  detect  if  the  connection to its IMP is looped by
  397.  
  398.      receiving a message with the wrong leader  format.   This  allows
  399.  
  400.      the host to take appropriate action upon detection of the loop.
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.                                    - 4 -
  414.  
  415.  
  416.  
  417.      1822L Host Access Protocol                          December 1983
  418.      RFC 878
  419.  
  420.  
  421.  
  422.      2.1  Addresses and Names
  423.  
  424.  
  425.      The 1822 protocol defines one form of host specification, and the
  426.  
  427.      1822L  protocol  defines  two additional ways to identify network
  428.  
  429.      hosts.  These three forms are 1822 addresses,  1822L  names,  and
  430.  
  431.      1822L addresses.
  432.  
  433.  
  434.      1822 addresses are  the  24-bit  host  addresses  found  in  1822
  435.  
  436.      leaders.  They have the following format:
  437.  
  438.  
  439.             1              8 9                              24
  440.            +----------------+---------------------------------+
  441.            |                |                                 |
  442.            |  Host number   |           IMP number            |
  443.            |                |                                 |
  444.            +----------------+---------------------------------+
  445.  
  446.  
  447.                             1822 Address Format
  448.                                 Figure 2.1
  449.  
  450.  
  451.  
  452.      These fields are quite large, and the ARPANET will never use more
  453.  
  454.      than  a  fraction of the available address space.  1822 addresses
  455.  
  456.      are used in 1822 leaders only.
  457.  
  458.  
  459.      1822L names are 16-bit unsigned numbers that serve as  a  logical
  460.  
  461.      identifier  for  one  or  more  hosts.   1822L  names have a much
  462.  
  463.      simpler format:
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.                                    - 5 -
  473.  
  474.  
  475.  
  476.      1822L Host Access Protocol                          December 1983
  477.      RFC 878
  478.  
  479.  
  480.  
  481.  
  482.  
  483.                      1                             16
  484.                     +--------------------------------+
  485.                     |                                |
  486.                     |           1822L name           |
  487.                     |                                |
  488.                     +--------------------------------+
  489.  
  490.  
  491.                              1822L Name Format
  492.                                 Figure 2.2
  493.  
  494.  
  495.  
  496.      The 1822L names are just 16-bit  unsigned  numbers,  except  that
  497.  
  498.      bits  1  and  2 are not both zeros (see below).  This allows over
  499.  
  500.      49,000 hosts to be specified.
  501.  
  502.  
  503.      1822 addresses cannot be used in 1822L leaders, but there may  be
  504.  
  505.      a  requirement for an 1822L host to be able to address a specific
  506.  
  507.      physical host port or IMP fake host.  1822L  addresses  are  used
  508.  
  509.      for  this  function.   1822L addresses form a subset of the 1822L
  510.  
  511.      name space, and have both bits 1 and 2 off.
  512.  
  513.  
  514.                     1   2  3          8 9             16
  515.                   +---+---+------------+----------------+
  516.                   |   |   |            |                |
  517.                   | 0 | 0 |   host #   |   IMP number   |
  518.                   |   |   |            |                |
  519.                   +---+---+------------+----------------+
  520.  
  521.  
  522.                            1822L Address Format
  523.                                 Figure 2.3
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.                                    - 6 -
  532.  
  533.  
  534.  
  535.      1822L Host Access Protocol                          December 1983
  536.      RFC 878
  537.  
  538.  
  539.  
  540.      This format allows 1822L hosts to directly address hosts 0-63  at
  541.  
  542.      IMPs  1-255  (IMP  0 does not exist).  Note that the highest host
  543.  
  544.      numbers are reserved  for  addressing  the  IMP's  internal  fake
  545.  
  546.      hosts.   At  this  writing, the IMP has seven fake hosts, so host
  547.  
  548.      numbers 57-63 address the IMP fake hosts, while host numbers 0-56
  549.  
  550.      address  real  hosts  external  to the IMP.  As the number of IMP
  551.  
  552.      fake hosts changes, this boundary point will also change.
  553.  
  554.  
  555.  
  556.  
  557.      2.2  Name Translations
  558.  
  559.  
  560.      There are a number of factors that determine how an 1822L name is
  561.  
  562.      translated  by  the  IMP  into a physical address on the network.
  563.  
  564.      These factors include which translations are legal; in what order
  565.  
  566.      different  translations  for  the  same name should be attempted;
  567.  
  568.      which  legal  translations  shouldn't  be  attempted  because   a
  569.  
  570.      particular  host  port  is down; and the interoperability between
  571.  
  572.      1822  and  1822L  hosts.   These  issues  are  discussed  in  the
  573.  
  574.      following sections.
  575.  
  576.  
  577.  
  578.  
  579.      2.2.1  Authorization and Effectiveness
  580.  
  581.  
  582.      Every host on a C/30 IMP, regardless of whether it is  using  the
  583.  
  584.      1822  or  1822L  protocol  to access the network, can have one or
  585.  
  586.      more 1822L names (logical addresses).  Hosts using 1822L can then
  587.  
  588.  
  589.  
  590.                                    - 7 -
  591.  
  592.  
  593.  
  594.      1822L Host Access Protocol                          December 1983
  595.      RFC 878
  596.  
  597.  
  598.  
  599.      use  these  names to address the hosts in the network independent
  600.  
  601.      of their  physical  locations.   Because  of  the  implementation
  602.  
  603.      constraints mentioned in the introduction, hosts on non-C/30 IMPs
  604.  
  605.      cannot be assigned 1822L names.  To circumvent this  restriction,
  606.  
  607.      however,  1822L  hosts can also use 1822L addresses to access all
  608.  
  609.      of the other hosts.
  610.  
  611.  
  612.      At this point, several questions  arise:   How  are  these  names
  613.  
  614.      assigned,  how  do  they  become  known  to  the  IMPs  (so  that
  615.  
  616.      translations to physical addresses can be made), and how  do  the
  617.  
  618.      IMPs know which host is currently using a shared port?  To answer
  619.  
  620.      each question in order:
  621.  
  622.  
  623.      Names are assigned by a central network administrator.  When each
  624.  
  625.      name  is  created, it is assigned to a host (or a group of hosts)
  626.  
  627.      at one or more specific host ports.  The host(s) are  allowed  to
  628.  
  629.      reside at those specific host ports, and nowhere else.  If a host
  630.  
  631.      moves, it will keep the same name, but the administrator  has  to
  632.  
  633.      update  the  central  database  to  reflect  the  new  host port.
  634.  
  635.      Changes to this database are  distributed  to  the  IMPs  by  the
  636.  
  637.      Network  Operations  Center  (NOC).  For a while, the host may be
  638.  
  639.      allowed to reside at either of (or both) the new and  old  ports.
  640.  
  641.      Once  the  correspondence  between  a  name and one or more hosts
  642.  
  643.      ports where it  may  be  used  has  been  made  official  by  the
  644.  
  645.      administrator,   that  name  is  said  to  be  authorized.  1822L
  646.  
  647.  
  648.  
  649.                                    - 8 -
  650.  
  651.  
  652.  
  653.      1822L Host Access Protocol                          December 1983
  654.      RFC 878
  655.  
  656.  
  657.  
  658.      addresses, which actually  refer  to  physical  host  ports,  are
  659.  
  660.      always authorized in this sense.
  661.  
  662.  
  663.      Once a host has been assigned one or more names, it  has  to  let
  664.  
  665.      the  IMPs  know  where it is and what name(s) it is using.  There
  666.  
  667.      are two cases to consider, one for 1822L hosts  and  another  for
  668.  
  669.      1822  hosts.   The following discussion only pertains to hosts on
  670.  
  671.      C/30 IMPs.
  672.  
  673.  
  674.      When an IMP sees an 1822L host come up on a host  port,  the  IMP
  675.  
  676.      has  no way of knowing which host has just come up (several hosts
  677.  
  678.      may share the same port, or one host may prefer to  be  known  by
  679.  
  680.      different  names  at different times).  This requires the host to
  681.  
  682.      declare itself to the IMP before it can actually send and receive
  683.  
  684.      messages.   This  function  is  performed  by  a  new host-to-IMP
  685.  
  686.      message, the Name Declaration  Message  (NDM),  which  lists  the
  687.  
  688.      names  that  the  host would like to be known by.  The IMP checks
  689.  
  690.      its tables to see if each of the names is authorized,  and  sends
  691.  
  692.      an  NDM  Reply  to  the  host  saying  which  names were actually
  693.  
  694.      authorized and can now be used for sending and receiving messages
  695.  
  696.      (i.e.,  which  names  are  effective). A host can also use an NDM
  697.  
  698.      message to change its list of effective names (it can add to  and
  699.  
  700.      delete  from  the  list) at any time.  The only constraint on the
  701.  
  702.      host is that any names it wishes to use can become effective only
  703.  
  704.      if they are authorized.
  705.  
  706.  
  707.  
  708.                                    - 9 -
  709.  
  710.  
  711.  
  712.      1822L Host Access Protocol                          December 1983
  713.      RFC 878
  714.  
  715.  
  716.  
  717.      In the second case, if a host comes up on a C/30  IMP  using  the
  718.  
  719.      1822 protocol, the IMP automatically makes the first name the IMP
  720.  
  721.      finds in its tables  for  that  host  become  effective  when  it
  722.  
  723.      receives the first 1822 NOP from the host.  Thus, even though the
  724.  
  725.      host is using the 1822 protocol, it can  still  receive  messages
  726.  
  727.      from  1822L  hosts  via  its  1822L name.  Of course, it can also
  728.  
  729.      receive messages from an 1822L host  via  its  1822L  address  as
  730.  
  731.      well.    (Remember,  the  distinction  between  1822L  names  and
  732.  
  733.      addresses is that the addresses correspond to physical  locations
  734.  
  735.      on   the   network,   while   the   names  are  strictly  logical
  736.  
  737.      identifiers).  The IMPs translate between the  different  leaders
  738.  
  739.      and send the proper leader in each case (see section 2.2.4).
  740.  
  741.  
  742.      The third question above has by now already been answered.   When
  743.  
  744.      an  1822L  host comes up, it uses the NDM message to tell the IMP
  745.  
  746.      which host it is (which names it is known by).  Even if this is a
  747.  
  748.      shared port, the IMP knows which host is currently connected.
  749.  
  750.  
  751.      Whenever a host goes down, its names  automatically  become  non-
  752.  
  753.      effective.   When it comes back up, it has to make them effective
  754.  
  755.      again.
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.                                   - 10 -
  768.  
  769.  
  770.  
  771.      1822L Host Access Protocol                          December 1983
  772.      RFC 878
  773.  
  774.  
  775.  
  776.      2.2.2  Translation Policies
  777.  
  778.  
  779.      Several hosts can share the same 1822L name.  If more than one of
  780.  
  781.      these  hosts  is  up  at the same time, any messages sent to that
  782.  
  783.      1822L name will be delivered to just one  of  the  hosts  sharing
  784.  
  785.      that  name,  and  a RFNM will be returned as usual.  However, the
  786.  
  787.      sending host will  not  receive  any  indication  of  which  host
  788.  
  789.      received  the  message,  and subsequent messages to that name are
  790.  
  791.      not guaranteed to be sent to the  same  host.   Typically,  hosts
  792.  
  793.      providing  exactly  the  same  service could share the same 1822L
  794.  
  795.      name in this manner.
  796.  
  797.  
  798.      Similarly, when a host is multi-homed, the same  1822L  name  may
  799.  
  800.      refer  to  more  than  one  host  port (all connected to the same
  801.  
  802.      host).  If the host is up on only one of those ports,  that  port
  803.  
  804.      will be used for all messages addressed to the host.  However, if
  805.  
  806.      the host were up on more than one  port,  the  message  would  be
  807.  
  808.      delivered  over  just  one  of  those ports, and the subnet would
  809.  
  810.      choose which port to use.  This port selection could change  from
  811.  
  812.      message  to  message.   If  a  host wanted to insure that certain
  813.  
  814.      messages were delivered to it on specific ports,  these  messages
  815.  
  816.      could  use  either  the  port's 1822L address or a specific 1822L
  817.  
  818.      name that referred to that port alone.
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.                                   - 11 -
  827.  
  828.  
  829.  
  830.      1822L Host Access Protocol                          December 1983
  831.      RFC 878
  832.  
  833.  
  834.  
  835.      Three different address selection policies are available for  the
  836.  
  837.      name mapping process.  When translated, each name uses one of the
  838.  
  839.      three policies  (the  policy  is  pre-determined  on  a  per-name
  840.  
  841.      basis).  The three policies are:
  842.  
  843.  
  844.      o  Attempt each translation in the order in  which  the  physical
  845.  
  846.         addresses  are listed in the IMP's translation tables, to find
  847.  
  848.         the first reachable  physical  host  address.   This  list  is
  849.  
  850.         always  searched  from the top whenever an uncontrolled packet
  851.  
  852.         is to be sent or a new virtual circuit connection  has  to  be
  853.  
  854.         created  (see  section  2.5).   This is the most commonly used
  855.  
  856.         policy.
  857.  
  858.  
  859.      o  Selection of the closest  physical  address,  which  uses  the
  860.  
  861.         IMP's   routing   tables   to  find  the  translation  to  the
  862.  
  863.         destination  IMP  with  the  least  delay  path  whenever   an
  864.  
  865.         uncontrolled  packet  is  to  be sent or a new virtual circuit
  866.  
  867.         connection has to be created.
  868.  
  869.  
  870.      o  Use load leveling. This is similar to the second  policy,  but
  871.  
  872.         differs  in  that  searching  the  address  list  for  a valid
  873.  
  874.         translation starts at the address following where the previous
  875.  
  876.         translation search ended whenever an uncontrolled packet is to
  877.  
  878.         be sent or a new virtual circuit connection has to be created.
  879.  
  880.         This  attempts to spread out the load from any one IMP's hosts
  881.  
  882.  
  883.  
  884.  
  885.                                   - 12 -
  886.  
  887.  
  888.  
  889.      1822L Host Access Protocol                          December 1983
  890.      RFC 878
  891.  
  892.  
  893.  
  894.         to the various host ports associated with a  particular  name.
  895.  
  896.         Note  that this is NOT network-wide load leveling, which would
  897.  
  898.         require a distributed algorithm and tables.
  899.  
  900.  
  901.  
  902.  
  903.      2.2.3  Reporting Destination Host Downs
  904.  
  905.  
  906.      As was explained in report 1822, and  as  will  be  discussed  in
  907.  
  908.      greater detail in section 2.5, whenever regular messages are sent
  909.  
  910.      by a host, the IMP opens a virtual  circuit  connection  to  each
  911.  
  912.      destination  host  from  the source host.  A connection will stay
  913.  
  914.      open at least as long as there are  any  outstanding  (un-RFNMed)
  915.  
  916.      messages  using it and both the source and destination hosts stay
  917.  
  918.      up.
  919.  
  920.  
  921.      However, the destination host may go down for some reason  during
  922.  
  923.      the  lifetime of a connection.  If the host goes down while there
  924.  
  925.      are no outstanding messages  to  it  in  the  network,  then  the
  926.  
  927.      connection  is  closed  and  no  other  action is taken until the
  928.  
  929.      source host submits the next message for  that  destination.   At
  930.  
  931.      that time, ONE of the following events will occur:
  932.  
  933.      A1.  If 1822 or an 1822L address is being  used  to  specify  the
  934.  
  935.           destination host, then the source host will receive a type 7
  936.  
  937.           (Destination Host Dead) message from the IMP.
  938.  
  939.      A2.  If an 1822L name is being used to  specify  the  destination
  940.  
  941.  
  942.  
  943.  
  944.                                   - 13 -
  945.  
  946.  
  947.  
  948.      1822L Host Access Protocol                          December 1983
  949.      RFC 878
  950.  
  951.  
  952.  
  953.           host,  and  the  name maps to only one authorized host port,
  954.  
  955.           then a type 7 message will also be sent to the source host.
  956.  
  957.      A3.  If an 1822L name is being used to  specify  the  destination
  958.  
  959.           host,  and  the  name  maps to more than one authorized host
  960.  
  961.           port, then the IMP attempts to open a connection to  another
  962.  
  963.           authorized  and  effective  host  port for that name.  If no
  964.  
  965.           such connection can be made, the host will receive a type 15
  966.  
  967.           (1822L  Name  or  Address  Error),  subtype  5 (no effective
  968.  
  969.           translations) message (see section 3.2).  Note that a type 7
  970.  
  971.           message  cannot be returned to the source host, since type 7
  972.  
  973.           messages refer to a particular destination  host  port,  and
  974.  
  975.           the name maps to more than one destination port.
  976.  
  977.  
  978.      Things get a bit more complicated if there  are  any  outstanding
  979.  
  980.      messages  on  the connection when the destination host goes down.
  981.  
  982.      The connection will be closed, and  one  of  the  following  will
  983.  
  984.      occur:
  985.  
  986.      B1.  If 1822 or an 1822L address is being  used  to  specify  the
  987.  
  988.           destination host, then the source host will receive a type 7
  989.  
  990.           message for each outstanding message.
  991.  
  992.      B2.  If an 1822L name is being used to  specify  the  destination
  993.  
  994.           host, then the source host will receive a type 9 (Incomplete  |
  995.  
  996.           Transmission), subtype 6  (message  lost  due  to  logically  |
  997.  
  998.           addressed  host  going  down)  message  for each outstanding  |
  999.  
  1000.  
  1001.  
  1002.  
  1003.                                   - 14 -
  1004.  
  1005.  
  1006.  
  1007.      1822L Host Access Protocol                          December 1983
  1008.      RFC 878
  1009.  
  1010.  
  1011.  
  1012.           message.  The next time  the  source  host  submits  another
  1013.  
  1014.           message   for  that  same  destination  name,  the  previous
  1015.  
  1016.           algorithm will be used (either step A2 or step A3).
  1017.  
  1018.  
  1019.      The above two algorithms also apply when a  host  stays  up,  but
  1020.  
  1021.      declares  the  destination  name for an existing connection to no
  1022.  
  1023.      longer be effective.  In this case, however, the type 7  messages
  1024.  
  1025.      above will be replaced by type 15, subtype 3 (name not effective)
  1026.  
  1027.      messages.
  1028.  
  1029.  
  1030.      Section 2.3 discusses how destination host downs are handled  for
  1031.  
  1032.      uncontrolled packets.
  1033.  
  1034.  
  1035.  
  1036.  
  1037.      2.2.4  1822L and 1822 Interoperability
  1038.  
  1039.  
  1040.      As  has  been  previously  stated,  1822  and  1822L  hosts   can
  1041.  
  1042.      intercommunicate,  and  the  IMPs  will  automatically handle any
  1043.  
  1044.      necessary leader and address format  conversions.   However,  not
  1045.  
  1046.      every   combination   of   1822   and  1822L  hosts  allows  full
  1047.  
  1048.      interoperability with regard to the use  of  1822L  names,  since
  1049.  
  1050.      1822 hosts are restricted to using physical addresses.
  1051.  
  1052.  
  1053.      There are two possible situations where any incompatibility could  |
  1054.  
  1055.      arise:                                                             |
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.                                   - 15 -
  1063.  
  1064.  
  1065.  
  1066.      1822L Host Access Protocol                          December 1983
  1067.      RFC 878
  1068.  
  1069.  
  1070.  
  1071.      o  An 1822 host sending a message to an  1822L  host:   The  1822  |
  1072.  
  1073.         host  specifies the destination host by its 1822 address.  The  |
  1074.  
  1075.         destination host will receive the message with an 1822L leader  |
  1076.  
  1077.         containing  the  1822L addresses of the source and destination  |
  1078.  
  1079.         hosts.                                                          |
  1080.  
  1081.  
  1082.      o  An 1822L host sending a message to an 1822  host:   The  1822L  |
  1083.  
  1084.         host  can  use  1822L  names  or addresses to specify both the  |
  1085.  
  1086.         source and  destination  hosts.   The  destination  host  will  |
  1087.  
  1088.         receive  the  message  with an 1822 leader containing the 1822  |
  1089.  
  1090.         address of the source host.                                     |
  1091.  
  1092.  
  1093.  
  1094.  
  1095.      2.3  Uncontrolled Packets
  1096.  
  1097.  
  1098.      Uncontrolled packets (see 1822(3.6)) present a unique problem for
  1099.  
  1100.      the  1822L protocol.  Uncontrolled packets use none of the normal
  1101.  
  1102.      ordering and error-control mechanisms in the IMP, and do not  use
  1103.  
  1104.      the  normal  virtual circuit connection facilities.  As a result,
  1105.  
  1106.      uncontrolled packets need to carry all  of  their  overhead  with
  1107.  
  1108.      them, including source and destination names.  If 1822L names are
  1109.  
  1110.      used when sending an uncontrolled packet, additional  information
  1111.  
  1112.      is  now required by the subnetwork when the packet is transferred
  1113.  
  1114.      to the destination IMP.  This means that less  host-to-host  data
  1115.  
  1116.      can  be  contained  in  the  packet than is possible between 1822
  1117.  
  1118.  
  1119.  
  1120.  
  1121.                                   - 16 -
  1122.  
  1123.  
  1124.  
  1125.      1822L Host Access Protocol                          December 1983
  1126.      RFC 878
  1127.  
  1128.  
  1129.  
  1130.      hosts.
  1131.  
  1132.  
  1133.      Uncontrolled packets that are sent between 1822 hosts may contain
  1134.  
  1135.      not  more  than  991 bits of data.  Uncontrolled packets that are
  1136.  
  1137.      sent to and/or from 1822L hosts are limited to 32 bits  less,  or
  1138.  
  1139.      not  more  than  959  bits.  Packets that exceed this length will
  1140.  
  1141.      result in an error indication to the host, and  the  packet  will
  1142.  
  1143.      not  be sent.  This error indication represents an enhancement to
  1144.  
  1145.      the previous level of service provided by the  IMP,  which  would
  1146.  
  1147.      simply   discard  an  overly  long  uncontrolled  packet  without
  1148.  
  1149.      notification.
  1150.  
  1151.  
  1152.      Other enhancements that  are  provided  for  uncontrolled  packet
  1153.  
  1154.      service  are  a  notification  to the host of any errors that are
  1155.  
  1156.      detected by the host's IMP when it receives the packet.   A  host
  1157.  
  1158.      will  be  notified if an uncontrolled packet contains an error in
  1159.  
  1160.      the 1822L  name  specification,  such  as  if  the  name  is  not
  1161.  
  1162.      authorized or effective, if the remote host is unreachable (which
  1163.  
  1164.      is indicated by none of its names being  effective),  if  network
  1165.  
  1166.      congestion control throttled the packet before it left the source
  1167.  
  1168.      IMP, or for any other reason the source IMP was not able to  send
  1169.  
  1170.      the packet on its way.
  1171.  
  1172.  
  1173.      In most cases, the host will not be notified if the  uncontrolled
  1174.  
  1175.      packet  was  lost  once  it  was  transmitted  by the source IMP.
  1176.  
  1177.  
  1178.  
  1179.  
  1180.                                   - 17 -
  1181.  
  1182.  
  1183.  
  1184.      1822L Host Access Protocol                          December 1983
  1185.      RFC 878
  1186.  
  1187.  
  1188.  
  1189.      However, the IMP will attempt to notify  the  source  host  if  a
  1190.  
  1191.      logically-addressed  uncontrolled packet was mistakenly sent to a
  1192.  
  1193.      host that the source IMP thought was effective, but which  turned
  1194.  
  1195.      out  to  be  dead  or non-effective at the destination IMP.  This
  1196.  
  1197.      non-delivery notice  is  sent  back  to  the  source  IMP  as  an
  1198.  
  1199.      uncontrolled  packet from the destination IMP, so the source host
  1200.  
  1201.      is not guaranteed to receive this indication.
  1202.  
  1203.  
  1204.      If the source IMP successfully receives the non-delivery  notice,
  1205.  
  1206.      then  the  source  host  will  receive  a  type 15 (1822L Name or
  1207.  
  1208.      Address Error), subtype 6 (down or non-effective  port)  message.
  1209.  
  1210.      If  the  packet  is  resubmitted or another packet is sent to the
  1211.  
  1212.      same destination name,  and  there  are  no  available  effective
  1213.  
  1214.      translations,  then  the  source  host  will  receive  a type 15,
  1215.  
  1216.      subtype 5 (no effective translations) message if the  destination
  1217.  
  1218.      name  has  more than one mapping; or will receive either a type 7
  1219.  
  1220.      (Destination Host Dead)  or  a  type  15,  subtype  3  (name  not
  1221.  
  1222.      effective)   message   if  the  destination  name  has  a  single
  1223.  
  1224.      translation.
  1225.  
  1226.  
  1227.      Those enhancements to the uncontrolled packet  service  that  are
  1228.  
  1229.      not  specific  to  logical  addressing will be available to hosts
  1230.  
  1231.      using 1822 as well as 1822L.  However, uncontrolled packets  must
  1232.  
  1233.      be  sent  using  1822L leaders in order to receive any indication
  1234.  
  1235.      that the packet was lost once it has left the source IMP.
  1236.  
  1237.  
  1238.  
  1239.                                   - 18 -
  1240.  
  1241.  
  1242.  
  1243.      1822L Host Access Protocol                          December 1983
  1244.      RFC 878
  1245.  
  1246.  
  1247.  
  1248.      2.4  Establishing Host-IMP Communications
  1249.  
  1250.  
  1251.      When a host comes up on an IMP, or after there has been  a  break
  1252.  
  1253.      in   the  communications  between  the  host  and  its  IMP  (see
  1254.  
  1255.      1822(3.2)), the orderly flow of messages between the host and the
  1256.  
  1257.      IMP  needs  to  be properly (re)established.  This allows the IMP
  1258.  
  1259.      and host to recover from most any failure  in  the  other  or  in
  1260.  
  1261.      their communications path, including a break in mid-message.
  1262.  
  1263.  
  1264.      The first messages that a host should send to its IMP  are  three
  1265.  
  1266.      NOP  messages.   Three  messages  are  required to insure that at
  1267.  
  1268.      least one message will be properly read by the IMP (the first NOP
  1269.  
  1270.      could be concatenated to a previous message if communications had
  1271.  
  1272.      been broken in mid-stream, and the third provides redundancy  for
  1273.  
  1274.      the   second).    These   NOPs   serve  several  functions:  they
  1275.  
  1276.      synchronize the IMP with the host, they tell  the  IMP  how  much
  1277.  
  1278.      padding  the  host  requires  between  the message leader and its
  1279.  
  1280.      body, and they also tell the IMP whether the host will  be  using
  1281.  
  1282.      1822 or 1822L leaders.
  1283.  
  1284.  
  1285.      Similarly, the IMP will send three  NOPs  to  the  host  when  it
  1286.  
  1287.      detects  that  the host has come up.  Actually, the IMP will send
  1288.  
  1289.      six NOPs, alternating three 1822  NOPs  with  three  1822L  NOPs.
  1290.  
  1291.      Thus, the host will see three NOPs no matter which protocol it is
  1292.  
  1293.      using.   The  NOPs  will  be  followed  by  two  Interface  Reset
  1294.  
  1295.  
  1296.  
  1297.  
  1298.                                   - 19 -
  1299.  
  1300.  
  1301.  
  1302.      1822L Host Access Protocol                          December 1983
  1303.      RFC 878
  1304.  
  1305.  
  1306.  
  1307.      messages,  one of each style.  If the IMP receives a NOP from the
  1308.  
  1309.      host while the above sequence is occurring,  the  IMP  will  only
  1310.  
  1311.      send  the  remainder  of  the NOPs and the Interface Reset in the
  1312.  
  1313.      proper style.  The 1822 NOPs will contain the 1822 address of the
  1314.  
  1315.      host interface, and the 1822L NOPs will contain the corresponding
  1316.  
  1317.      1822L address.
  1318.  
  1319.  
  1320.      Once the IMP  and  the  host  have  sent  each  other  the  above
  1321.  
  1322.      messages, regular communications can commence.  See 1822(3.2) for
  1323.  
  1324.      further details concerning the ready line,  host  tardiness,  and
  1325.  
  1326.      other issues.
  1327.  
  1328.  
  1329.  
  1330.  
  1331.      2.5  Counting RFNMs When Using 1822L
  1332.  
  1333.  
  1334.      When a host submits a regular message using an 1822  leader,  the
  1335.  
  1336.      IMP  checks  for  an  existing simplex virtual circuit connection
  1337.  
  1338.      (see 1822(3.1)) from the source host to the destination host.  If
  1339.  
  1340.      such  a  connection already exists, it is used.  Otherwise, a new
  1341.  
  1342.      connection from the source host port to the destination host port
  1343.  
  1344.      is  opened.   In either case, there may be at most eight messages
  1345.  
  1346.      outstanding on that connection  at  any  one  time.   If  a  host
  1347.  
  1348.      submits  a  ninth message on that connection before it receives a
  1349.  
  1350.      reply for the first message, then the host will be blocked  until
  1351.  
  1352.      the reply is sent for the first message.
  1353.  
  1354.  
  1355.  
  1356.  
  1357.                                   - 20 -
  1358.  
  1359.  
  1360.  
  1361.      1822L Host Access Protocol                          December 1983
  1362.      RFC 878
  1363.  
  1364.  
  1365.  
  1366.      Such connections can stay open for some time, but are  timed  out
  1367.  
  1368.      after  three minutes of no activity, or can be closed if there is
  1369.  
  1370.      contention for the connection blocks  in  either  the  source  or
  1371.  
  1372.      destination  IMP.   However, a connection will never be closed as
  1373.  
  1374.      long as there are any outstanding messages on it.  This allows  a
  1375.  
  1376.      source  host  to  count the number of replies it has received for
  1377.  
  1378.      messages to each destination host address in order to avoid being
  1379.  
  1380.      blocked   by  submitting  a  ninth  outstanding  message  on  any
  1381.  
  1382.      connection.
  1383.  
  1384.  
  1385.      When a host submits a regular message using an  1822L  leader,  a
  1386.  
  1387.      similar process occurs, except that in this case, connections are
  1388.  
  1389.      distinguished by the  source  port/source  name/destination  name
  1390.  
  1391.      combination.   When  the message is received from a host, the IMP
  1392.  
  1393.      first looks for an open connection for that same port and  source
  1394.  
  1395.      name/destination  name pair.  If such a connection is found, then
  1396.  
  1397.      it is used, and no further name translation  is  performed.   If,
  1398.  
  1399.      however,  no open connection was found, then the destination name
  1400.  
  1401.      is translated, and a connection opened to the physical host port.
  1402.  
  1403.      As  long  as there are any outstanding messages on the connection
  1404.  
  1405.      it will stay open, and it will have  the  same  restriction  that
  1406.  
  1407.      only  eight messages may be outstanding at any one time.  Thus, a
  1408.  
  1409.      source host can still count replies to avoid being  blocked,  but
  1410.  
  1411.      they must be counted on a source port and source name/destination
  1412.  
  1413.  
  1414.  
  1415.  
  1416.                                   - 21 -
  1417.  
  1418.  
  1419.  
  1420.      1822L Host Access Protocol                          December 1983
  1421.      RFC 878
  1422.  
  1423.  
  1424.  
  1425.      name pair basis, instead of just by source port  and  destination
  1426.  
  1427.      host address as before.
  1428.  
  1429.  
  1430.      Since connections are based on the source name  as  well  as  the
  1431.  
  1432.      destination  name,  this  implies that there may be more than one
  1433.  
  1434.      open connection from physical host port A to physical  host  port
  1435.  
  1436.      B,   which   would   allow   more  than  8  outstanding  messages
  1437.  
  1438.      simultaneously from the first to the second port.   However,  for
  1439.  
  1440.      this  to  occur, either the source or destination names, or both,
  1441.  
  1442.      must differ from one connection to the next.  For example, if the
  1443.  
  1444.      names  "543"  and  "677" both translate to physical port 3 on IMP
  1445.  
  1446.      51, then the host on that port could  open  four  connections  to
  1447.  
  1448.      itself  by  sending  messages  from "543" to "543", from "543" to
  1449.  
  1450.      "677", from "677" to "543", and from "677" to "677".
  1451.  
  1452.  
  1453.      As has already been stated,  the  destination  names  in  regular
  1454.  
  1455.      messages  are  only translated when connections are first opened.
  1456.  
  1457.      Once a connection is open, that connection, and  its  destination
  1458.  
  1459.      physical  host port, will continue to be used until it is closed.
  1460.  
  1461.      If, in the meantime, a "better" destination host  port  belonging
  1462.  
  1463.      to  the  same  destination name became available, it would not be
  1464.  
  1465.      used until the next time a  new  connection  is  opened  to  that
  1466.  
  1467.      destination name.
  1468.  
  1469.  
  1470.  
  1471.  
  1472.  
  1473.  
  1474.  
  1475.                                   - 22 -
  1476.  
  1477.  
  1478.  
  1479.      1822L Host Access Protocol                          December 1983
  1480.      RFC 878
  1481.  
  1482.  
  1483.  
  1484.      Also, the act of making an 1822L name be non-effective  will  not  |
  1485.  
  1486.      automatically cause any connections using that name to be closed.  |
  1487.  
  1488.      However, they will be closed  after  at  most  three  minutes  of  |
  1489.  
  1490.      inactivity.  A host can, if it wishes, make all of its names at a  |
  1491.  
  1492.      port be noneffective and close all of its connections to and from  |
  1493.  
  1494.      the port by flapping the host's ready line to that IMP port.       |
  1495.  
  1496.  
  1497.  
  1498.  
  1499.      2.6  1822L Name Server
  1500.  
  1501.  
  1502.      There may  be  times  when  a  host  wants  to  perform  its  own
  1503.  
  1504.      translations,  or  might need the full list of physical addresses
  1505.  
  1506.      to which a particular name maps.  For example, a connection-based
  1507.  
  1508.      host-to-host  protocol  may  require  that the same physical host
  1509.  
  1510.      port on a multi-homed host be used for all  messages  using  that
  1511.  
  1512.      host-to-host  connection, and the host does not wish to trust the
  1513.  
  1514.      IMP to always deliver messages using a destination  name  to  the
  1515.  
  1516.      same host port.
  1517.  
  1518.  
  1519.      In these cases, the host  can  submit  a  type  11  (Name  Server
  1520.  
  1521.      Request)  message to the IMP, which requests the IMP to translate
  1522.  
  1523.      the destination 1822L name and return a list of the addresses  to
  1524.  
  1525.      which  it maps.  The IMP will respond with a type 11 (Name Server
  1526.  
  1527.      Reply) message, which contains the selection policy  in  use  for
  1528.  
  1529.      that  name,  the  number of addresses to which the name maps, the
  1530.  
  1531.  
  1532.  
  1533.  
  1534.                                   - 23 -
  1535.  
  1536.  
  1537.  
  1538.      1822L Host Access Protocol                          December 1983
  1539.      RFC 878
  1540.  
  1541.  
  1542.  
  1543.      addresses  themselves,  and  for  each  address,  whether  it  is
  1544.  
  1545.      effective and its routing distance from the IMP.  See section 3.2
  1546.  
  1547.      for a complete description of the message's contents.
  1548.  
  1549.  
  1550.      Using this information, the source host could  make  an  informed
  1551.  
  1552.      decision  on which of the physical host ports corresponding to an
  1553.  
  1554.      1822L name to use and then send the messages to that port, rather
  1555.  
  1556.      than to the name.
  1557.  
  1558.  
  1559.      The IMP also supports a different type of name service.   A  host
  1560.  
  1561.      needs  to issue a Name Declaration Message to the IMP in order to
  1562.  
  1563.      make its names effective, but it may not wish to keep  its  names
  1564.  
  1565.      in  some table or file in the host.  In this case, it can ask the
  1566.  
  1567.      IMP to tell it which names it is authorized to use.
  1568.  
  1569.  
  1570.      In this case, the host submits a  type  12  (Port  List  Request)
  1571.  
  1572.      message to the IMP, and the IMP replies with a type 12 (Port List
  1573.  
  1574.      Reply) message.  It contains, for the host port  over  which  the
  1575.  
  1576.      IMP  received the request and sent the reply, the number of names
  1577.  
  1578.      that map to the port, the list of names, and whether or not  each
  1579.  
  1580.      name  is  effective.   The  host can then use this information in
  1581.  
  1582.      order  to  issue  the  Name  Declaration  Message.   Section  3.2
  1583.  
  1584.      contains a complete description of the reply's contents.
  1585.  
  1586.  
  1587.  
  1588.  
  1589.  
  1590.  
  1591.  
  1592.  
  1593.                                   - 24 -
  1594.  
  1595.  
  1596.  
  1597.      1822L Host Access Protocol                          December 1983
  1598.      RFC 878
  1599.  
  1600.  
  1601.  
  1602.      3  1822L LEADER FORMATS
  1603.  
  1604.  
  1605.      The following sections describe the formats of the  leaders  that
  1606.  
  1607.      precede  messages  between  an 1822L host and its IMP.  They were
  1608.  
  1609.      designed to be as compatible with the 1822 leaders  as  possible.
  1610.  
  1611.      The  second,  fifth,  and  sixth  words  are identical in the two
  1612.  
  1613.      leaders, and all  of  the  existing  functionality  of  the  1822
  1614.  
  1615.      leaders  has  been  retained.   In  the  first word, the 1822 New
  1616.  
  1617.      Format Flag is now also used to identify the two types  of  1822L
  1618.  
  1619.      leaders, and the Handling Type has been moved to the second byte.
  1620.  
  1621.      The third and fourth words contain  the  Source  and  Destination
  1622.  
  1623.      1822L Name, respectively.
  1624.  
  1625.  
  1626.  
  1627.  
  1628.  
  1629.  
  1630.  
  1631.  
  1632.  
  1633.  
  1634.  
  1635.  
  1636.  
  1637.  
  1638.  
  1639.  
  1640.  
  1641.  
  1642.  
  1643.  
  1644.  
  1645.  
  1646.  
  1647.  
  1648.  
  1649.  
  1650.  
  1651.  
  1652.                                   - 25 -
  1653.  
  1654.  
  1655.  
  1656.      1822L Host Access Protocol                          December 1983
  1657.      RFC 878
  1658.  
  1659.  
  1660.  
  1661.      3.1  Host-to-IMP 1822L Leader Format
  1662.  
  1663.  
  1664.  
  1665.  
  1666.                     1      4 5      8 9             16
  1667.                    +--------+--------+----------------+
  1668.                    |        |  1822L |                |
  1669.                    | Unused |  H2I   | Handling Type  |
  1670.                    |        |  Flag  |                |
  1671.                    +--------+--------+----------------+
  1672.                     17    20 21 22 24 25            32
  1673.                    +--------+-+------+----------------+
  1674.                    |        |T|Leader|                |
  1675.                    | Unused |R|Flags |  Message Type  |
  1676.                    |        |C|      |                |
  1677.                    +--------+-+------+----------------+
  1678.                     33                              48
  1679.                    +----------------------------------+
  1680.                    |                                  |
  1681.                    |           Source Host            |
  1682.                    |                                  |
  1683.                    +----------------------------------+
  1684.                     49                              64
  1685.                    +----------------------------------+
  1686.                    |                                  |
  1687.                    |         Destination Host         |
  1688.                    |                                  |
  1689.                    +----------------------------------+
  1690.                     65                     76 77    80
  1691.                    +-------------------------+--------+
  1692.                    |                         |        |
  1693.                    |       Message ID        |Sub-type|
  1694.                    |                         |        |
  1695.                    +-------------------------+--------+
  1696.                     81                              96
  1697.                    +----------------------------------+
  1698.                    |                                  |
  1699.                    |              Unused              |
  1700.                    |                                  |
  1701.                    +----------------------------------+
  1702.  
  1703.  
  1704.                       Host-to-IMP 1822L Leader Format
  1705.                                 Figure 3.1
  1706.  
  1707.  
  1708.  
  1709.  
  1710.  
  1711.                                   - 26 -
  1712.  
  1713.  
  1714.  
  1715.      1822L Host Access Protocol                          December 1983
  1716.      RFC 878
  1717.  
  1718.  
  1719.  
  1720.      Bits 1-4: Unused, must be set to zero.
  1721.  
  1722.  
  1723.      Bits 5-8: 1822L Host-to-IMP Flag:
  1724.  
  1725.           This field is set to decimal 13 (1101 in binary).
  1726.  
  1727.  
  1728.      Bits 9-16: Handling Type:
  1729.  
  1730.           This  field  is  bit-coded  to  indicate  the   transmission
  1731.  
  1732.           characteristics  of  the connection desired by the host. See
  1733.  
  1734.           1822(3.3).
  1735.  
  1736.           Bit 9: Priority Bit:
  1737.  
  1738.                Messages with this bit on will be treated  as  priority
  1739.  
  1740.                messages.
  1741.  
  1742.           Bits 10-16: Unused, must be zero.
  1743.  
  1744.  
  1745.      Bits 17-20: Unused, must be zero.
  1746.  
  1747.  
  1748.      Bit 21: Trace Bit:
  1749.  
  1750.           If equal to one, this message is designated for  tracing  as
  1751.  
  1752.           it proceeds through the network.  See 1822(5.5).
  1753.  
  1754.  
  1755.      Bits 22-24: Leader Flags:
  1756.  
  1757.           Bit 22: A flag available for use by  the  destination  host.
  1758.  
  1759.                See 1822(3.3) for a description of its use by the IMP's
  1760.  
  1761.                TTY Fake Host.
  1762.  
  1763.           Bits 23-24: Reserved for future use, must be zero.
  1764.  
  1765.  
  1766.  
  1767.  
  1768.  
  1769.  
  1770.                                   - 27 -
  1771.  
  1772.  
  1773.  
  1774.      1822L Host Access Protocol                          December 1983
  1775.      RFC 878
  1776.  
  1777.  
  1778.  
  1779.      Bits 25-32: Message Type:
  1780.  
  1781.           Type 0: Regular Message  -  All  host-to-host  communication
  1782.  
  1783.                occurs  via  regular  messages, which have several sub-
  1784.  
  1785.                types, found in bits 77-80.  These sub-types are:
  1786.  
  1787.                0: Standard - The IMP uses its full message  and  error
  1788.  
  1789.                     control facilities, and host blocking may occur.
  1790.  
  1791.                3: Uncontrolled  Packet  -  The  IMP  will  perform  no
  1792.  
  1793.                     message-control   functions   for   this  type  of
  1794.  
  1795.                     message, and network flow and  congestion  control
  1796.  
  1797.                     may  cause loss of the packet.  Also see 1822(3.6)
  1798.  
  1799.                     and section 2.3.
  1800.  
  1801.                1-2,4-15: Unassigned.
  1802.  
  1803.           Type 1: Error Without Message ID - See 1822(3.3).
  1804.  
  1805.           Type 2: Host Going Down - see 1822(3.3).
  1806.  
  1807.           Type 3: Name Declaration Message (NDM)  -  This  message  is
  1808.  
  1809.                used by the host to declare which of its 1822L names is
  1810.  
  1811.                or is not effective (see section 2.2.1), or to make all
  1812.  
  1813.                of  its  names non-effective.  The first 16 bits of the
  1814.  
  1815.                data portion of the NDM message, following  the  leader
  1816.  
  1817.                and  any  leader  padding, contains the number of 1822L
  1818.  
  1819.                names contained in the message.  This  is  followed  by
  1820.  
  1821.                the 1822L name entries, each 32 bits long, of which the
  1822.  
  1823.                first 16 bits is a 1822L name and the  second  16  bits
  1824.  
  1825.                contains  either  of  the  integers  zero or one.  Zero
  1826.  
  1827.  
  1828.  
  1829.                                   - 28 -
  1830.  
  1831.  
  1832.  
  1833.      1822L Host Access Protocol                          December 1983
  1834.      RFC 878
  1835.  
  1836.  
  1837.  
  1838.                indicates that the name should not  be  effective,  and
  1839.  
  1840.                one  indicates  that the name should be effective.  The
  1841.  
  1842.                IMP will reply with a NDM Reply  message  (see  section
  1843.  
  1844.                3.2)  indicating  which  of the names are now effective
  1845.  
  1846.                and which are not.  Pictorially, a NDM message has  the
  1847.  
  1848.                following   format  (including  the  leader,  which  is
  1849.  
  1850.                printed  in  hexadecimal,  and   without   any   leader
  1851.  
  1852.                padding):
  1853.  
  1854.  
  1855.  
  1856.  
  1857.  
  1858.  
  1859.  
  1860.  
  1861.  
  1862.  
  1863.  
  1864.  
  1865.  
  1866.  
  1867.  
  1868.  
  1869.  
  1870.  
  1871.  
  1872.  
  1873.  
  1874.  
  1875.  
  1876.  
  1877.  
  1878.  
  1879.  
  1880.  
  1881.  
  1882.  
  1883.  
  1884.  
  1885.  
  1886.  
  1887.  
  1888.                                   - 29 -
  1889.  
  1890.  
  1891.  
  1892.      1822L Host Access Protocol                          December 1983
  1893.      RFC 878
  1894.  
  1895.  
  1896.  
  1897.  
  1898.  
  1899.                  1             16 17            32 33            48
  1900.                 +----------------+----------------+----------------+
  1901.                 |                |                |                |
  1902.                 |      0D00      |      0003      |      0000      |
  1903.                 |                |                |                |
  1904.                 +----------------+----------------+----------------+
  1905.                  49            64 65            80 81            96
  1906.                 +----------------+----------------+----------------+
  1907.                 |                |                |                |
  1908.                 |      0000      |      0000      |      0000      |
  1909.                 |                |                |                |
  1910.                 +----------------+----------------+----------------+
  1911.                  97           112 113          128 129          144
  1912.                 +----------------+----------------+----------------+
  1913.                 |                |                |                |
  1914.                 |  # of entries  |  1822L name #1 |     0 or 1     |
  1915.                 |                |                |                |
  1916.                 +----------------+----------------+----------------+
  1917.                 145           160 161          176
  1918.                 +----------------+----------------+
  1919.                 |                |                |
  1920.                 |  1822L name #2 |     0 or 1     |       etc.
  1921.                 |                |                |
  1922.                 +----------------+----------------+
  1923.  
  1924.  
  1925.                             NDM Message Format
  1926.                                 Figure 3.2
  1927.  
  1928.  
  1929.  
  1930.                An  NDM  with  zero  entries  will  cause  all  current
  1931.  
  1932.                effective names for the host to become non-effective.
  1933.  
  1934.           Type 4: NOP - This allows the IMP to  know  which  style  of
  1935.  
  1936.                leader  the  host wishes to use.  A 1822L NOP signifies
  1937.  
  1938.                that the host wishes to use 1822L leaders, and an  1822
  1939.  
  1940.                NOP signifies that the host wishes to use 1822 leaders.
  1941.  
  1942.                All of the other remarks concerning the NOP message  in
  1943.  
  1944.  
  1945.  
  1946.  
  1947.                                   - 30 -
  1948.  
  1949.  
  1950.  
  1951.      1822L Host Access Protocol                          December 1983
  1952.      RFC 878
  1953.  
  1954.  
  1955.  
  1956.                1822(3.3)  still  hold.   The  host should always issue
  1957.  
  1958.                NOPs in groups of three to insure proper  reception  by
  1959.  
  1960.                the IMP.  Also see section 2.4 for a further discussion
  1961.  
  1962.                on the use of the NOP message.
  1963.  
  1964.           Type 8: Error with Message ID - see 1822(3.3).
  1965.  
  1966.           Type 11: Name Server Request - This allows the host  to  use
  1967.  
  1968.                the  IMP's  logical addressing tables as a name server.
  1969.  
  1970.                The destination name in the 1822L leader is translated,
  1971.  
  1972.                and  the  IMP replies with a Name Server Reply message,
  1973.  
  1974.                which lists the physical host addresses  to  which  the
  1975.  
  1976.                destination name maps.
  1977.  
  1978.           Type 12: Port List Request - This allows the  physical  host
  1979.  
  1980.                to  request the list of names that map to the host port
  1981.  
  1982.                over which this request was received by the  IMP.   The
  1983.  
  1984.                IMP replies with a Port List Reply message, which lists
  1985.  
  1986.                the names that map to the port.
  1987.  
  1988.           Types 5-7,9-10,13-255: Unassigned.
  1989.  
  1990.  
  1991.      Bits 33-48: Source Host:
  1992.  
  1993.           This field contains one of the  source  host's  1822L  names
  1994.  
  1995.           (or,  alternatively,  the 1822L address of the host port the
  1996.  
  1997.           message  is  being  sent   over).    This   field   is   not
  1998.  
  1999.           automatically filled in by the IMP, as in the 1822 protocol,
  2000.  
  2001.           because the host may be known by several names and may  wish
  2002.  
  2003.  
  2004.  
  2005.  
  2006.                                   - 31 -
  2007.  
  2008.  
  2009.  
  2010.      1822L Host Access Protocol                          December 1983
  2011.      RFC 878
  2012.  
  2013.  
  2014.  
  2015.           to use a particular name as the source of this message.  All
  2016.  
  2017.           messages from the same host need not use the  same  name  in
  2018.  
  2019.           this  field.   Each  source  name, when used, is checked for
  2020.  
  2021.           authorization, effectiveness, and actually belonging to this
  2022.  
  2023.           host.  Messages using names that do not satisfy all of these
  2024.  
  2025.           requirements will not be delivered, and will instead  result
  2026.  
  2027.           in  an  error  message being sent back into the source host.
  2028.  
  2029.           If the host places its 1822L  address  in  this  field,  the
  2030.  
  2031.           address is checked to insure that it actually represents the
  2032.  
  2033.           host port where the message originated.
  2034.  
  2035.  
  2036.      Bits 49-64: Destination Host:
  2037.  
  2038.           This field  contains  the  1822L  name  or  address  of  the
  2039.  
  2040.           destination  host.   If it contains a name, the name will be
  2041.  
  2042.           checked for effectiveness, with an error message returned to
  2043.  
  2044.           the source host if the name is not effective.
  2045.  
  2046.  
  2047.      Bits 65-76: Message ID:
  2048.  
  2049.           This is a host-specified identification used in all  type  0
  2050.  
  2051.           and  type  8  messages, and is also used in type 2 messages.
  2052.  
  2053.           When used in type 0 messages, bits 65-72 are also  known  as
  2054.  
  2055.           the  Link  Field,  and  should  contain  values specified in
  2056.  
  2057.           Assigned  Numbers  [3]  appropriate  for  the   host-to-host
  2058.  
  2059.           protocol being used.
  2060.  
  2061.  
  2062.  
  2063.  
  2064.  
  2065.                                   - 32 -
  2066.  
  2067.  
  2068.  
  2069.      1822L Host Access Protocol                          December 1983
  2070.      RFC 878
  2071.  
  2072.  
  2073.  
  2074.      Bits 77-80: Sub-type:
  2075.  
  2076.           This field is used as a modifier by message types 0,  2,  4,
  2077.  
  2078.           and 8.
  2079.  
  2080.  
  2081.      Bits 81-96: Unused, must be zero.
  2082.  
  2083.  
  2084.  
  2085.  
  2086.  
  2087.  
  2088.  
  2089.  
  2090.  
  2091.  
  2092.  
  2093.  
  2094.  
  2095.  
  2096.  
  2097.  
  2098.  
  2099.  
  2100.  
  2101.  
  2102.  
  2103.  
  2104.  
  2105.  
  2106.  
  2107.  
  2108.  
  2109.  
  2110.  
  2111.  
  2112.  
  2113.  
  2114.  
  2115.  
  2116.  
  2117.  
  2118.  
  2119.  
  2120.  
  2121.  
  2122.  
  2123.  
  2124.                                   - 33 -
  2125.  
  2126.  
  2127.  
  2128.      1822L Host Access Protocol                          December 1983
  2129.      RFC 878
  2130.  
  2131.  
  2132.  
  2133.      3.2  IMP-to-Host 1822L Leader Format
  2134.  
  2135.  
  2136.  
  2137.  
  2138.                     1      4 5      8 9             16
  2139.                    +--------+--------+----------------+
  2140.                    |        |  1822L |                |
  2141.                    | Unused |  I2H   | Handling Type  |
  2142.                    |        |  Flag  |                |
  2143.                    +--------+--------+----------------+
  2144.                     17    20 21 22 24 25            32
  2145.                    +--------+-+------+----------------+
  2146.                    |        |T|Leader|                |
  2147.                    | Unused |R|Flags |  Message Type  |
  2148.                    |        |C|      |                |
  2149.                    +--------+-+------+----------------+
  2150.                     33                              48
  2151.                    +----------------------------------+
  2152.                    |                                  |
  2153.                    |           Source Host            |
  2154.                    |                                  |
  2155.                    +----------------------------------+
  2156.                     49                              64
  2157.                    +----------------------------------+
  2158.                    |                                  |
  2159.                    |         Destination Host         |
  2160.                    |                                  |
  2161.                    +----------------------------------+
  2162.                     65                     76 77    80
  2163.                    +-------------------------+--------+
  2164.                    |                         |        |
  2165.                    |       Message ID        |Sub-type|
  2166.                    |                         |        |
  2167.                    +-------------------------+--------+
  2168.                     81                              96
  2169.                    +----------------------------------+
  2170.                    |                                  |
  2171.                    |          Message Length          |
  2172.                    |                                  |
  2173.                    +----------------------------------+
  2174.  
  2175.  
  2176.                       IMP-to-Host 1822L Leader Format
  2177.                                 Figure 3.3
  2178.  
  2179.  
  2180.  
  2181.  
  2182.  
  2183.                                   - 34 -
  2184.  
  2185.  
  2186.  
  2187.      1822L Host Access Protocol                          December 1983
  2188.      RFC 878
  2189.  
  2190.  
  2191.  
  2192.      Bits 1-4: Unused and set to zero.
  2193.  
  2194.  
  2195.      Bits 5-8: 1822L IMP-to-Host Flag:
  2196.  
  2197.           This field is set to decimal 14 (1110 in binary).
  2198.  
  2199.  
  2200.      Bits 9-16: Handling Type:
  2201.  
  2202.           This has the value assigned by the source host (see  section
  2203.  
  2204.           3.1).   This field is only used in message types 0, 5-9, and
  2205.  
  2206.           15.
  2207.  
  2208.  
  2209.      Bits 17-20: Unused and set to zero.
  2210.  
  2211.  
  2212.      Bit 21: Trace Bit:
  2213.  
  2214.           If equal to one, the source host designated this message for
  2215.  
  2216.           tracing as it proceeds through the network.  See 1822(5.5).
  2217.  
  2218.  
  2219.      Bits 22-24: Leader Flags:
  2220.  
  2221.           Bit 22: Available as a destination host flag.
  2222.  
  2223.           Bits 23-24: Reserved for future use, set to zero.
  2224.  
  2225.  
  2226.      Bits 25-32: Message Type:
  2227.  
  2228.           Type 0: Regular Message  -  All  host-to-host  communication
  2229.  
  2230.                occurs  via  regular  messages, which have several sub-
  2231.  
  2232.                types.  The sub-type field (bits 77-80) is the same  as
  2233.  
  2234.                sent in the host-to-IMP leader (see section 3.1).
  2235.  
  2236.           Type 1: Error in Leader - See 1822(3.4).  In addition to its  |
  2237.  
  2238.                already  defined  sub-types,  this  message has two new  |
  2239.  
  2240.  
  2241.  
  2242.                                   - 35 -
  2243.  
  2244.  
  2245.  
  2246.      1822L Host Access Protocol                          December 1983
  2247.      RFC 878
  2248.  
  2249.  
  2250.  
  2251.                sub-types:                                               |
  2252.  
  2253.                4: Illegal Leader Style - The host submitted  a  leader  |
  2254.  
  2255.                     in  which  bits  5-8 did not contain the value 13,  |
  2256.  
  2257.                     14, or 15 decimal.                                  |
  2258.  
  2259.                5: Wrong Leader Style - The  host  submitted  an  1822L  |
  2260.  
  2261.                     leader  when the IMP was expecting an 1822 leader,  |
  2262.  
  2263.                     or vice-versa.                                      |
  2264.  
  2265.           Type 2: IMP Going Down - See 1822(3.4).
  2266.  
  2267.           Type 3: NDM Reply - This is a reply to the  NDM  host-to-IMP
  2268.  
  2269.                message  (see  section  3.1).   It  will  have the same
  2270.  
  2271.                number of entries as the  NDM  message  that  is  being
  2272.  
  2273.                replying  to,  and  each  listed  1822L  name  will  be
  2274.  
  2275.                accompanied by a zero or a one  (see  figure  3.2).   A
  2276.  
  2277.                zero  signifies  that  the name is not effective, and a
  2278.  
  2279.                one means that the name is now effective.
  2280.  
  2281.           Type 4: NOP - The host should discard this message.   It  is
  2282.  
  2283.                used    during    initialization    of   the   IMP/host
  2284.  
  2285.                communication.  The Destination Host field will contain
  2286.  
  2287.                the  1822L  Address of the host port over which the NOP
  2288.  
  2289.                is being sent.  All other fields are unused.
  2290.  
  2291.           Type 5: Ready for Next Message (RFNM) - See 1822(3.4).
  2292.  
  2293.           Type 6: Dead Host Status - See 1822(3.4).
  2294.  
  2295.           Type 7: Destination Host or IMP  Dead  (or  unknown)  -  See
  2296.  
  2297.                1822(3.4).
  2298.  
  2299.  
  2300.  
  2301.                                   - 36 -
  2302.  
  2303.  
  2304.  
  2305.      1822L Host Access Protocol                          December 1983
  2306.      RFC 878
  2307.  
  2308.  
  2309.  
  2310.           Type 8: Error in Data - See 1822(3.4).
  2311.  
  2312.           Type  9:  Incomplete  Transmission  -  See  1822(3.4).    In  |
  2313.  
  2314.                addition to its already defined sub-types, this message  |
  2315.  
  2316.                has one new sub-type:                                    |
  2317.  
  2318.                6: Logically Addressed Host Went  Down  -  A  logically  |
  2319.  
  2320.                     addressed  message was lost in the network because  |
  2321.  
  2322.                     the  destination  host  to  which  it  was   being  |
  2323.  
  2324.                     delivered   went  down.   The  message  should  be  |
  2325.  
  2326.                     resubmitted by the source host, since there may be  |
  2327.  
  2328.                     another  effective  host port to which the message  |
  2329.  
  2330.                     could be delivered (see section 2.2.3).             |
  2331.  
  2332.           Type 10: Interface Reset - See 1822(3.4).
  2333.  
  2334.           Type 11: Name Server Reply - This reply to the  Name  Server
  2335.  
  2336.                Request  host-to-IMP  message  contains,  following the
  2337.  
  2338.                leader  and  any  leader  padding,  a  word  with   the
  2339.  
  2340.                selection  policy  and the number of physical addresses
  2341.  
  2342.                to which the destination name  maps,  followed  by  two
  2343.  
  2344.                words  per physical address: the first word contains an
  2345.  
  2346.                1822L address, and  the  second  word  contains  a  bit
  2347.  
  2348.                signifying  whether  or not that particular translation
  2349.  
  2350.                is effective and the routing distance (expected network
  2351.  
  2352.                transmission  delay,  in 6.4 ms units) to the address's
  2353.  
  2354.                IMP.  In figure 3.4, which includes the leader  without
  2355.  
  2356.                any  leader  padding,  EFF is 1 for effective and 0 for
  2357.  
  2358.  
  2359.  
  2360.                                   - 37 -
  2361.  
  2362.  
  2363.  
  2364.      1822L Host Access Protocol                          December 1983
  2365.      RFC 878
  2366.  
  2367.  
  2368.  
  2369.                non-effective, and POL is a two-bit  number  indicating
  2370.  
  2371.                the selection policy for the name (see section 2.2.2):
  2372.  
  2373.                0: First reachable.
  2374.  
  2375.                1: Closest physical address.
  2376.  
  2377.                2: Load leveling.
  2378.  
  2379.                3: Unused.
  2380.  
  2381.  
  2382.  
  2383.                  1             16 17            32 33            48
  2384.                 +----------------+----------------+----------------+
  2385.                 |                |                |                |
  2386.                 |      0E00      |      000B      |      0000      |
  2387.                 |                |                |                |
  2388.                 +----------------+----------------+----------------+
  2389.                  49            64 65            80 81            96
  2390.                 +----------------+----------------+----------------+
  2391.                 |                |                |                |
  2392.                 |   dest. name   |      0000      |      0000      |
  2393.                 |                |                |                |
  2394.                 +----------------+----------------+----------------+
  2395.                  97           112 113          128 129          144
  2396.                 +-+--------------+----------------+-+--------------+
  2397.                 |P|              |                |E|              |
  2398.                 |O|  # of addrs  |  1822L addr #1 |F| routing dist |
  2399.                 |L|              |                |F|              |
  2400.                 +-+--------------+----------------+-+--------------+
  2401.                 145           160 161          176
  2402.                 +----------------+-+--------------+
  2403.                 |                |E|              |
  2404.                 |  1822L addr #2 |F| routing dist |       etc.
  2405.                 |                |F|              |
  2406.                 +----------------+-+--------------+
  2407.  
  2408.  
  2409.                          Name Server Reply Format
  2410.                                 Figure 3.4
  2411.  
  2412.  
  2413.  
  2414.  
  2415.  
  2416.  
  2417.  
  2418.  
  2419.                                   - 38 -
  2420.  
  2421.  
  2422.  
  2423.      1822L Host Access Protocol                          December 1983
  2424.      RFC 878
  2425.  
  2426.  
  2427.  
  2428.           Type 12: Port List Reply - This is the  reply  to  the  Port
  2429.  
  2430.                List  Request  host-to-IMP  message.   It  contains the
  2431.  
  2432.                number of names that map to this  physical  host  port,
  2433.  
  2434.                followed by two words per name: the first word contains
  2435.  
  2436.                an 1822L name that maps to this port,  and  the  second
  2437.  
  2438.                contains  either a zero or a one, signifying whether or
  2439.  
  2440.                not that  particular  translation  is  effective.   The
  2441.  
  2442.                format  is  identical  to  the type 3 NDM Reply message
  2443.  
  2444.                (see figure 3.2).
  2445.  
  2446.           Type 15: 1822L Name or Address Error - This message is  sent
  2447.  
  2448.                in  response  to  a  type  0  message  from a host that
  2449.  
  2450.                contained an erroneous Source Host or Destination  Host
  2451.  
  2452.                field.  Its sub-types are:
  2453.  
  2454.                0: The Source Host 1822L name is not authorized or  not
  2455.  
  2456.                     effective.
  2457.  
  2458.                1: The Source Host 1822L address  does  not  match  the
  2459.  
  2460.                     host port used to send the message.
  2461.  
  2462.                2: The Destination Host 1822L name is not authorized.
  2463.  
  2464.                3:  The  physical  host  to  which  this   singly-homed
  2465.  
  2466.                     Destination Host name translated is authorized and
  2467.  
  2468.                     up, but not effective.  If the host  was  actually
  2469.  
  2470.                     down,  a  type  7 message would be returned, not a
  2471.  
  2472.                     type 15.
  2473.  
  2474.                5: The multi-homed Destination Host name is authorized,
  2475.  
  2476.  
  2477.  
  2478.                                   - 39 -
  2479.  
  2480.  
  2481.  
  2482.      1822L Host Access Protocol                          December 1983
  2483.      RFC 878
  2484.  
  2485.  
  2486.  
  2487.                     but has no available effective translations.
  2488.  
  2489.                6: A logically-addressed uncontrolled packet  was  sent
  2490.  
  2491.                     to a dead or non-effective host port.  However, if
  2492.  
  2493.                     it is resubmitted, there may be another  effective
  2494.  
  2495.                     host  port to which the IMP may be able to attempt
  2496.  
  2497.                     to send the packet.
  2498.  
  2499.                7: Logical addressing is not in use in this network.
  2500.  
  2501.                8-15: Unassigned.
  2502.  
  2503.           Types 4,13-14,16-255: Unassigned.
  2504.  
  2505.  
  2506.      Bits 33-48: Source Host:
  2507.  
  2508.           For type 0 messages, this field contains the 1822L  name  or
  2509.  
  2510.           address  of  the  host  that  originated  the  message.  All
  2511.  
  2512.           replies to the message should be sent to the host  specified
  2513.  
  2514.           herein.   For  message types 5-9 and 15, this field contains
  2515.  
  2516.           the source host field used in a previous type 0 message sent
  2517.  
  2518.           by this host.
  2519.  
  2520.  
  2521.      Bits 49-64: Destination Host:
  2522.  
  2523.           For type 0 messages, this field contains the 1822L  name  or
  2524.  
  2525.           address  that  the  message  was  sent  to.  This allows the
  2526.  
  2527.           destination host to detect  how  it  was  specified  by  the
  2528.  
  2529.           source  host.   For  message  types  5-9  and 15, this field
  2530.  
  2531.           contains the destination host field used in a previous  type
  2532.  
  2533.           0 message sent by this host.
  2534.  
  2535.  
  2536.  
  2537.                                   - 40 -
  2538.  
  2539.  
  2540.  
  2541.      1822L Host Access Protocol                          December 1983
  2542.      RFC 878
  2543.  
  2544.  
  2545.  
  2546.      Bits 65-76: Message ID:
  2547.  
  2548.           For message types 0, 5, 7-9,  and  15,  this  is  the  value
  2549.  
  2550.           assigned  by  the  source  host to identify the message (see
  2551.  
  2552.           section 3.1).  This field is also used by  message  types  2
  2553.  
  2554.           and 6.
  2555.  
  2556.  
  2557.      Bits 77-80: Sub-type:
  2558.  
  2559.           This field is used as a modifier by message types 0-2,  5-7,
  2560.  
  2561.           9, and 15.
  2562.  
  2563.  
  2564.      Bits 81-96: Message Length:
  2565.  
  2566.           This field is contained in type 0, 3, 11,  and  12  messages
  2567.  
  2568.           only,  and  is  the  actual  length  in  bits of the message
  2569.  
  2570.           (exclusive of leader, leader padding, and hardware  padding)
  2571.  
  2572.           as computed by the IMP.
  2573.  
  2574.  
  2575.  
  2576.  
  2577.  
  2578.  
  2579.  
  2580.  
  2581.  
  2582.  
  2583.  
  2584.  
  2585.  
  2586.  
  2587.  
  2588.  
  2589.  
  2590.  
  2591.  
  2592.  
  2593.  
  2594.  
  2595.  
  2596.                                   - 41 -
  2597.  
  2598.  
  2599.  
  2600.      1822L Host Access Protocol                          December 1983
  2601.      RFC 878
  2602.  
  2603.  
  2604.  
  2605.      4  REFERENCES
  2606.  
  2607.  
  2608.      [1]  "Specifications for the Interconnection of  a  Host  and  an
  2609.  
  2610.           IMP", BBN Report 1822, December 1981 Revision.
  2611.  
  2612.  
  2613.      [2]  E.  C.   Rosen   et.   al.,   "ARPANET   Routing   Algorithm
  2614.  
  2615.           Improvements",   Internet   Experimenter's  Note  183  (also
  2616.  
  2617.           published as BBN Report 4473, Vol. 1), August 1980, pp.  55-
  2618.  
  2619.           107.
  2620.  
  2621.  
  2622.      [3]  J. Reynolds and J. Postel, "Assigned Numbers",  Request  For
  2623.  
  2624.           Comments 870, October 1983, p. 14.
  2625.  
  2626.  
  2627.      [4]  J. Postel, ed., "Internet Protocol - DARPA Internet  Program
  2628.  
  2629.           Protocol Specification", Request for Comments 791, September
  2630.  
  2631.           1981.
  2632.  
  2633.  
  2634.      [5]  J. Postel, "Address Mappings",  Request  for  Comments  796,
  2635.  
  2636.           September 1981.
  2637.  
  2638.  
  2639.  
  2640.  
  2641.  
  2642.  
  2643.  
  2644.  
  2645.  
  2646.  
  2647.  
  2648.  
  2649.  
  2650.  
  2651.  
  2652.  
  2653.  
  2654.  
  2655.                                   - 42 -
  2656.  
  2657.  
  2658.  
  2659.      1822L Host Access Protocol                          December 1983
  2660.      RFC 878
  2661.  
  2662.  
  2663.  
  2664.                                 APPENDIX A
  2665.  
  2666.  
  2667.                          1822L-IP ADDRESS MAPPINGS
  2668.  
  2669.  
  2670.  
  2671.      Once logical addressing is in active  (or  universal)  use  in  a  |
  2672.  
  2673.      network,  to  the extent that the "official" host tables for that  |
  2674.  
  2675.      network specify hosts by their logical names rather than by their  |
  2676.  
  2677.      physical  network  addresses,  it would be desirable for hosts on  |
  2678.  
  2679.      other networks to also be able to use the same logical  names  to  |
  2680.  
  2681.      specify these hosts when sending traffic to them via the internet  |
  2682.  
  2683.      [4].                                                               |
  2684.  
  2685.  
  2686.      Happily, there exists a natural mapping between logical names and  |
  2687.  
  2688.      internet  addresses  that  fits  very  nicely  with  the  already  |
  2689.  
  2690.      standard ARPANET-style address mapping as specified in  RFC  796,  |
  2691.  
  2692.      Address  Mappings [5].  The current ARPANET-style class A mapping  |
  2693.  
  2694.      is as follows (from RFC 796):                                      |
  2695.  
  2696.  
  2697.  
  2698.  
  2699.  
  2700.  
  2701.  
  2702.  
  2703.  
  2704.  
  2705.  
  2706.  
  2707.  
  2708.  
  2709.  
  2710.  
  2711.  
  2712.  
  2713.  
  2714.                                   - 43 -
  2715.  
  2716.  
  2717.  
  2718.      1822L Host Access Protocol                          December 1983
  2719.      RFC 878
  2720.  
  2721.  
  2722.  
  2723.  
  2724.  
  2725.              +--------+ +--------+--------+
  2726.              |  HOST  | |  ZERO  |  IMP   |    1822 Address
  2727.              +--------+ +--------+--------+
  2728.                  8          8        8
  2729.  
  2730.              +--------+--------+--------+--------+
  2731.              | net #  |  HOST  |   LH   |  IMP   |   IP Address
  2732.              +--------+--------+--------+--------+
  2733.                  8        8        8        8
  2734.  
  2735.  
  2736.                            1822 Class A Mapping
  2737.                                 Figure A.1
  2738.  
  2739.  
  2740.  
  2741.      For 1822L names and addresses, the mapping would be:               |
  2742.  
  2743.  
  2744.  
  2745.              +--------+--------+
  2746.              | upper  | lower  |     1822L Name or Address
  2747.              +--------+--------+
  2748.                  8        8
  2749.  
  2750.              +--------+--------+--------+--------+
  2751.              | net #  | upper  |   LH   | lower  |   IP Address
  2752.              +--------+--------+--------+--------+
  2753.                  8        8        8        8
  2754.  
  2755.  
  2756.                            1822L Class A Mapping
  2757.                                 Figure A.2
  2758.  
  2759.  
  2760.  
  2761.      For 1822L addresses,  this  mapping  is  identical  to  the  1822  |
  2762.  
  2763.      mapping.   For  1822L  names,  the  IP address would appear to be  |
  2764.  
  2765.      addressing a high-numbered (64-255) 1822 host.  Although  the  LH  |
  2766.  
  2767.      (logical  host)  field  is still defined, its use is discouraged;  |
  2768.  
  2769.      multiple logical names should now be used to  multiplex  multiple  |
  2770.  
  2771.  
  2772.  
  2773.                                   - 44 -
  2774.  
  2775.  
  2776.  
  2777.      1822L Host Access Protocol                          December 1983
  2778.      RFC 878
  2779.  
  2780.  
  2781.  
  2782.      functions onto one physical host port.                             |
  2783.  
  2784.  
  2785.      This mapping extends to class B networks:                          |
  2786.  
  2787.  
  2788.  
  2789.              +--------+--------+
  2790.              | upper  | lower  |     1822L Name or Address
  2791.              +--------+--------+
  2792.                  8        8
  2793.  
  2794.              +----------------+--------+--------+
  2795.              | network number | upper  | lower  |   IP Address
  2796.              +----------------+--------+--------+
  2797.                      16            8        8
  2798.  
  2799.  
  2800.                            1822L Class B Mapping
  2801.                                 Figure A.3
  2802.  
  2803.  
  2804.  
  2805.      Finally, logical addressing will allow IMP-based class C networks  |
  2806.  
  2807.      for  the  first  time.   Previously,  it  was very hard to try to  |
  2808.  
  2809.      divide the 8 bits of host specification into some number of  host  |
  2810.  
  2811.      bits  and  some  number  of  IMP  bits.   However,  if ALL of the  |
  2812.  
  2813.      internet-accessible hosts on  the  network  have  logical  names,  |
  2814.  
  2815.      there is no reason why networks with up to 256 such logical names  |
  2816.  
  2817.      cannot now use class C addresses, as follows:                      |
  2818.  
  2819.  
  2820.  
  2821.  
  2822.  
  2823.  
  2824.  
  2825.  
  2826.  
  2827.  
  2828.  
  2829.  
  2830.  
  2831.  
  2832.                                   - 45 -
  2833.  
  2834.  
  2835.  
  2836.      1822L Host Access Protocol                          December 1983
  2837.      RFC 878
  2838.  
  2839.  
  2840.  
  2841.  
  2842.  
  2843.              +--------+--------+
  2844.              |01000000| lower  |     1822L Name
  2845.              +--------+--------+
  2846.                  8        8
  2847.  
  2848.              +------------------------+--------+
  2849.              |     network number     | lower  |   IP Address
  2850.              +------------------------+--------+
  2851.                          24                8
  2852.  
  2853.  
  2854.                            1822L Class C Mapping
  2855.                                 Figure A.4
  2856.  
  2857.  
  2858.  
  2859.      Those hosts on the network  desiring  internet  access  would  be  |
  2860.  
  2861.      assigned  logical  names in the range 40000 to 40377 (octal), and  |
  2862.  
  2863.      the  gateway(s)  connected  to  that  network  would   make   the  |
  2864.  
  2865.      translation  from IP addresses to 1822L names as specified above.  |
  2866.  
  2867.      Note that the network could have many more than 256 hosts, or 256  |
  2868.  
  2869.      defined  names;  the  only  restriction is that hosts that desire  |
  2870.  
  2871.      internet support or access be addressable by a name in the  range  |
  2872.  
  2873.      40000  -  40377.   Traffic that was strictly local to the network  |
  2874.  
  2875.      could use other names or even 1822L addresses.                     |
  2876.  
  2877.  
  2878.  
  2879.  
  2880.  
  2881.  
  2882.  
  2883.  
  2884.  
  2885.  
  2886.  
  2887.  
  2888.  
  2889.  
  2890.  
  2891.                                   - 46 -
  2892.  
  2893.  
  2894.  
  2895.      1822L Host Access Protocol                          December 1983
  2896.      RFC 878
  2897.  
  2898.  
  2899.  
  2900.                                    INDEX
  2901.  
  2902.  
  2903.  
  2904.  
  2905.  
  2906.  
  2907.      1822...................................................... 3
  2908.      1822 address.............................................. 5
  2909.      1822 host................................................. 4
  2910.      1822L..................................................... 3
  2911.      1822L address............................................. 6
  2912.      1822L and 1822 interoperability.......................... 15
  2913.      1822L host................................................ 4
  2914.      1822L name................................................ 5
  2915.      address selection policy................................. 12
  2916.      authorized................................................ 8
  2917.      blocking................................................. 20
  2918.      closest physical address................................. 12
  2919.      connection............................................... 20
  2920.      destination host..................................... 32, 40
  2921.      effective............................................. 9, 23
  2922.      first reachable.......................................... 12
  2923.      handing type......................................... 27, 35
  2924.      host downs............................................... 13
  2925.      interoperability......................................... 15
  2926.      leader flags......................................... 27, 35
  2927.      link field............................................... 32
  2928.      load leveling............................................ 12
  2929.      logical addressing........................................ 3
  2930.      message ID........................................... 32, 41
  2931.      message length........................................... 41
  2932.      message type......................................... 28, 35
  2933.      multi-homing.............................................. 3
  2934.      name server...................................... 23, 31, 37
  2935.      NDM................................................... 9, 28
  2936.      NDM reply............................................. 9, 36
  2937.      NOC....................................................... 8
  2938.      NOP........................................... 4, 19, 30, 36
  2939.      priority bit............................................. 27
  2940.      regular message...................................... 28, 35
  2941.      RFNM................................................. 20, 36
  2942.      source host.......................................... 31, 40
  2943.      standard message......................................... 28
  2944.      sub-type............................................. 33, 41
  2945.      symmetric................................................. 4
  2946.      trace bit............................................ 27, 35
  2947.  
  2948.  
  2949.  
  2950.                                   - 47 -
  2951.  
  2952.  
  2953.  
  2954.      1822L Host Access Protocol                          December 1983
  2955.      RFC 878
  2956.  
  2957.  
  2958.  
  2959.      uncontrolled packet.................................. 16, 28
  2960.      virtual circuit connection............................... 20
  2961.  
  2962.  
  2963.  
  2964.  
  2965.  
  2966.  
  2967.  
  2968.  
  2969.  
  2970.  
  2971.  
  2972.  
  2973.  
  2974.  
  2975.  
  2976.  
  2977.  
  2978.  
  2979.  
  2980.  
  2981.  
  2982.  
  2983.  
  2984.  
  2985.  
  2986.  
  2987.  
  2988.  
  2989.  
  2990.  
  2991.  
  2992.  
  2993.  
  2994.  
  2995.  
  2996.  
  2997.  
  2998.  
  2999.  
  3000.  
  3001.  
  3002.  
  3003.  
  3004.  
  3005.  
  3006.  
  3007.  
  3008.  
  3009.                                   - 48 -
  3010.  
  3011.